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1 .0  Introduction 

This  report  summarizes  the  work  performed  during  the  tenth  quarter  of 
this  contract,  from  March  15,-1984  to  June  14,  1984.  The  work  in  this 
quarter  concentrated  in  three  areas:  simulations  of  our  real-time  bidding 
algorithm,  non- traditional  architectures  studies  for  real-time  systems,  and 
scheduling  tasks  with  resource  requirements  in  hard  real-time  systems. 
Section  2  of  this  report  describes  the  progress  made  in  each  of  these  areas.. 

Significant  new  results  were  obtained  in  the  area  of  hard  real-time 
constraints  and  a  paper  was  written  describing  these  results.  A  copy  of  the 
paper  is  attached  as  Appendix  A.  > 


2.1  Real-Time  Constraints  -  Simulations 


During  the  past  few  months,  progress  has  been  made  in  f  incizing  the 
simulation  model  of  distributed  hard  real-time  systems  and  evaluating  the 
performance  of  a  basic  bidding  algorithm  in  such  a  system. "vSignif leant 
results  have  been  obtained  which  provides  insight  into  the  effectiveness  of. 
the  algorithm.  An  improvement  over  the  basic  algorithm  has  been  found.  The 
improvement  uses  the  prediction  of  future  surplus  time  instead  of  the  cur¬ 
rent  surplus  time  in  modifying  bids.  This  report  describes  the  basic 
algorithm  and  then  describes  the  simulation  results. 

Each  node  in  the  distributed  system  has  a  scheduler.  A  set  (possibly 
null)  of  guaranteed  periodic  tasks  exist  at  each  node.  Aperiodic  tasks  may 
arrive  at  any  node  in  the  network.  When  a  new  task  arrives,  an  attempt  will 
be  made  to  schedule  the  task  at  that  node.  If  this  is  not  possible,  then 
the  scheduler  on  the  node  interacts  with  the  schedulers  on  other  nodes, 
using  a  bidding  scheme,  in  order  to  determine  the  node  on  which  the  task  can 
be  sent  to  be  scheduled.  The  intent  is  to  guarantee  all  periodic  tasks  and 
as  many  of  the  aperiodic  tasks  as  possible,  utilizing  the  resources  of  the 
entire  network. 


The  scheduler  is  decomposed  into  two  major  system  tasks:  a  local 
scheduler  task  and  a  bidder  task.  They  may  be  invoked  periodically  or 
asynchronously.  The  local  scheduler  task  invokes  the  guarantee  routine  to 
check  to  see  if  a  newly  arriving  task  can  be  guaranteed  locally.  If  yes, 
the  task  is  linked  to  the  ready  queue  and  is  dispatched  with  an  earliest 
deadline  policy.  If  not,  the  task  is  linked  to  an  outgoing  RFB  (request- 
for-bid)  queue  waiting  to  be  processed  by  the  bidder  task.  The  bidder  task 
has  three  phases.  The  first  phase  is  to  evaluate  the  tasks  in  the  outgoing 
RFB  queue  and  send  out  the  RFB  messages  in  behalf  of  the  tasks.  The  second 
phase  is  to  evaluate  the  incoming  RFB  message  queue  and  send  out  the  bids. 
The  third  phase  is  to  evaluate  the  queue  of  returning  bids  to  see  if  there 
is  a  node  where  the  task  can  be  sent  to  be  scheduled. 

In  a  hard  real-time  environment,  the  bidding  algorithm  must  run  in  a 
timely  fashion.  Each  RFB  message  i3  attached  with  a  deadline  of  response. 
If  the  responding  site  cannot  deliver  the  bid  to  the  request  site  on  time, 
no  attempt  will  actually  be  made.  Therefore,  only  viable  bids  will  reach 
the  request  site  and  the  communication  overhead  may  be  reduced.  In  reply  to 
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a  RFB  message,  a  node  estimated  the  surplus  time  available  for  the  task  be* 
tween  the  estimated  arrival  time  and  the  deadline  of  the  task  and  sends  the 
surplus  time  as  the  bid  to  the  request  site.  The  estimation  is  based  on  the 
assumption  that  the  surplus  time  in  the  near  future  will  be  about  the  same 
as  that  in  the  recent  past.  This  assumption  has  been  found  inadequate  in  a 
hard  realntime  environment  and  needs  to  be  modified. 

Our  simulation  has  provided  some  insight  into  the  performance  of  the 
bidding  algorithm  under  various  conditions  (arrival  rates,  processing  power 
of  system  tasks,  length  of  memory  accumulation  periods).  Several  baseline 
algorithms  are  simulated  to  bound  the  performance  of  the  bidding  algorithm. 
The  performance  matric  used  is  the  number  of  tasks  guaranteed  in  the 
networknwide  system.  Other  statistics  collected  include  the  utilization 
factors  and  the  turnaround  time.  The  turnaround  time  is  defined  to  be  the 
time  interval  between  the  arrival  time  and  the  time  when  a  task  i3 
guaranteed  or  found  to  be  impossible  to  guarantee  (locally  or  at  remote 
sites) . 

Table  1  illustrates  the  number  of  tasks  guaranteed  under  various  ar* 
rival  rates  of  aperiodic  tasks.  The  percentage  of  the  total  number  of  tasks 
guaranteed  decreases  and  the  turnaround  time  at  heavily  loaded  sites  in* 
creases  as  the  arrival  rate  is  increased.  This  is  because  the  processing 
power  of  the  system  tasks  is  limited  at  the  heavily  loaded  3ites  and  only  a 
certain  number  of  messages  may  be  processed  in  time.  Also  shown  in  the 
table,  at  rate  3  and  4,  the  input  stream  of  aperiodic  tasks  starts  to 
saturate  the  processing  power  of  the  system  tasks  to  the  load  factor  of  the 
aperiodic  tasks. 


rate  1 

rate  2 

rate  3 

rate  4 

Percentage  of  Tasks 

Guaranteed 

97.6? 

89.3? 

77.5? 

63.7? 

Normalized  Total  No. 

Tasks  Guaranteed 

1 

1.023 

0.966 

0.849 

Turnaround  Time 

host  1 

1 .5  msec 

1 .1  msec 

1 . 1  msec 

1 .0  msec 

host  2 

362.0 

608.4 

916.1 

3364.6 

host  3 

1 .0 

1.0 

1 .0 

1 .0 

host  4 

4.3 

43.3 

96.4 

121 .8 

host  5 

355.0  • 

662.0 

854.4 

1112.9 

Utilization  Factor 
host  1 

0.69 

0.76 

0.68 

0.50 

host  2 

1  ;00 

1 .00 

1 .00 

1 .00 

host  3 

0.66 

0.72 

0.66 

0;45 

host  4 

0.99 

1 .00 

1.00 

1.00 

host  5 

1  .00 

1  ;00 

1 .00 

1 .00 

Table  1.  Performance  of  the  Basic  Bidding  Algorithm  under 
Different  Arrival  Rates  of  Aperiodic  Tasks. 


We  have  also  evaluated  the  effect  of  changing  the  seeds  of  the  random 
number  generators  on  the  statistics.  Four  set  of  seeds  have  been  used. 
They  only  result  in  2.6$  difference  in  the  total  number  of  guaranteed  tasks. 
This  convinces  is  that  10$  improvement  over  the  performance  matrics  is 
significant. 

The  effect  of  varying  the  length  of  the  memory  accumulation  period 
(LMAP)  is  also  evaluated.  As  shown  in  Figure  1,  for  three  arrival  rates  the 
LMAP  is  varied  from  500  msec  to  3,000  msec.  Only  a  small  perturbation  in 
the  percentage  of  tasks  guaranteed  (less  than  1.9$)  is  observed.  This  in* 
sensitivity  to  LMAP  is  further  investigated  by  analyzing  the  variation  of 
the  surplus  time  during  the  run  time. 

As  shown  in  Figure  2,  the  surplus  times  are  recorded  and  plotted  as  a 
function  of  the  simulation  time.  Several  interesting  things  are  observed. 
First,  less  transient  behavior  is  exhibited  by  the  curves  in  which  higher 
LMAP's  are  used.  Second,  there  is  large  sinusoidal  pattern  of  surplus  times 
at  lightly  loaded  hosts  (host  1  and  3).  Third,  the  variations  of  the 
surplus  time  factor  for  host  1  and  3  complement  each  other. 

Since  the  surplus  at  host  1  and  3  vary  alternatively,  they  also  take 
turns  in  dominating  in  the  bidding  process.  When  the  surplus  for  one  host 
is  increased  above  the  cross  over  point;  the  host  starts  to  take  over  the 
bidding,  while  the  other  ceases  to  bid.  But  as  long  as  the  dominating  host 
has  enough  surplus,  viable  bids  will  be  issued  and  task  will  be  awarded  to 
this  site.  Therefore,  performance  depends  in  whether  there  is  a  host  with 
high  surplus  most  of  the  time.  When  all  the  hosts  are  low  in  surplus,  few 
viable  bids  are  issued  resulting  in  few  guaranteed  tasks  due  to  bidding. 

From  the  sinusoidal  pattern  of  surplus  time,  we  infer  there  is  an  over¬ 
bidding  and  an  underbidding  effect  in  the  peak  area  and  the  valley  area  of 
the  curves,  respectively.  In  the  peak  area,  because  of  the  high  current 
surplus  and  the  unawareness  of  the  outcome  of  the  bidding,  the  number  of 
bids  issued  may  be  more  than  that  can  be  accomodated  by  the  host.  As  a 
result,  conflicts  are  more  likely  to  occur  among  task  with  the  same  hard 
real-time  constraints.  In  the  valley  area,  because  of  the  low  current 
surplus  and  the  unawareness  of  the  shrinking  set  of  local  guaranteed  tasks, 
the  host  may  withdraw  itself  from  bidding  and  stay  idle  too  long  until  it 
finds  out  that  it  has  high  surplus  again.  Because  of  the  delay,  the  host 
will  waste  cpu  time  in  waiting  for  tasks  to  be  awarded.  The  underbidding 
effect  will  result  in  the  low  utilization  of  the  system. 
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Figure  1.  Effect  oi  varying  LMAF. 
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From  the  overbidding  and  underbidding  effects,  we  conclude  that  the 
original  algorithm  which  based  the  estimation  of  surplus  in  the  near  future 
on  the  surplus  in  the  recent  past  is  not  adequate  for  the  bidding  algorithm 
in  distributed  hard  real-time  systems.  The  estimation  should  be  based  in 
the  prediction  of  the  future  task  load  instead.  As  a  result,  the  bids 
issued  by  the  hosts  are  more  accurate  which  hopefully  will  result  in  more 
uniform  utilization  of  the  system.  A  proposed  approach  is  described  as 
follows:  Let  FT1ME  be  the  maximum  free  time  available  in  each  LCM  of  the 
periods  of  the  periodic  tasks,  i.e.,  FTIME  is  equal  to  LCM  minus  CPU  time 
reserved  for  the  periodic  tasks.  The  surplus  time  available  for  a  task  of 
which  the  estimated  arrival  time  and  the  deadline  are  ART  and  D,  respec* 
tively,  is  equal  to 


D*ART 

*  FTIME  a  CPU  time  needed  for  future  tasks, 

LCM 

where  the  future  tasks  include  guaranteed  tasks  of  which  the  deadlines  are 
between  ART  and  D,  and  the  tasks  which  will  be  arriving  and  guaranteed  as  a 
result  of  the  bidding.  The  estimation  of  the  number  of  tasks  which  will  be 
arriving  and  guaranteed  may  be  a  heuristic  function  of  the  number  of  out* 
standing  bids  and  the  surplus  time  ratio  between  local  host  and  other  hosts. 
We  expect  that  this  approach  will  eliminate  the  sinusoidal  pattern  and 
achieve  higher  utilization  of  the  system  resources.  This  new  approach  is 
currently  under  investigation. 

We  have  also  made  a  simulation  runs  to  bound  the  performance  of  the 
bidding  algorithm.  Several  baseline  algorithms  were  conceived:  1)  Perfect 
state  information  algorithm  (PSA)  -»  Each  node  is  assumed  to  have  perfect 
state  information  about  every  other  nodes  so  that  the  local  schedular  is 
capable  of  determining  whether  a  task  can  be  guaranteed  at  any  other  site  or 
not.  2)  Current  utilization  information  algorithm  (CUA)  *  Each  node  is  as* 
sumed  to  have  uprto«date  CPU  utilization  information  about  every  other  nodes 
all  the  time,  and  the  decision  of  choosing  the  node  to  send  the  task  is 
based  on  utilization.  3)  Random  scheduling  algorithm  (RSA)  *  Each  node  ran* 
domly  chooses  a  node  whenever  a  task  cannot  be  guaranteed  locally.  4)  Non- 
cooperative  algorithm  (NCA)  *  No  cooperation  among  nodes  is  assumed.  If  a 
task  cannot  be  guaranteed  locally,  it  simply  fails.  PSA  and  CUA  impose  up*> 
per  bounds  on  the  percentage  of  tasks  guaranteed,  while  RSA  and  NCA  impose 
lower  bounds. 

The  simulation  are  run  for  various  arrival  rates  of  aperiodic  tasks. 
At  rate  1  and  2,  the  numbers  of  tasks  arriving  in  each  least  common  multiple 
of  periods  of  periodic  tasks  are  84. 5 %  and  94%  of  the  maximum  number  of 
tasks  guaranteeable,  respectively.  As  shown  in  Figure  3,  the  bidding  algo¬ 
rithm  outperforms  the  lower  bound  algorithms  significantly  at  rate  1  and  2, 
which  are  pretty  high  arrival  rates  of  tasks. 

Fran  the  simulation  results  described  above,  we  conclude  that  the  bid" 
ding  algorithm  is  effective  in  scheduling  tasks  in  the  distributed  hard 
real<-time  systems  and  even  with  a  basic  bidding  algorithm,  it  yields  satis*- 
factory  performance  under  heavy  loads.  The  improvement  needed  for  the  basic 
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bidding  algorithm  is  to  use  the  prediction  of  the  arriving  tasks  in  the  near 
future  in  the  estimation  of  the  future  surplus  time  so  that  the  overbidding 
and  the  underbidding  effects  may  be  eliminated.  Under  saturation  condition, 
the  performance  degrades  which  should  be  avoided  by  adjusting  the  processing 
power  of  the  system  tasks  if  there  is  surplus  time  available. 

2.2  Real-Time  Constraints  g  Non- traditional  Architectures 

Under  this  contract  we  have  developed  a  flexible  scheduling  algorithm 
for  distributed  real-time  systems.  This  approach  is  based  on  a  local 
guarantee  algorithm  and  a  network-wide  bidding  algorithm.  A  task  that 
enters  a  host  is  scheduled  to  run  on  it  if  it  can  be  guaranteed  to  execute 
by  its  deadline.  If  not,  the  local  scheduler  calls  a  bidder  routine  which 
interacts  with  the  other  hosts  to  determine  if  the  task  can  be  elsewhere. 
Thus  the  other  hosts  "bid"  for  the  task  in  response  to  the  "request  for  bid" 
initiated  by  the  local  host. 

In  this  scheme,  every  host  posses  a  group  of  interacting  processes: 
the  local  guarantee  routine,  the  bidder,  the  scheduler  and  user  tasks. 
Because  of  the  logical  separation  of  these  processes,  we  feel  that  the  hosts 
can  be  designed  as  multiple  processor  systems,  with  each  of  the  above 
processes  mappings  onto  separate  processors.  The  two  main  advantages  of 
this  scheme  are  those  of  increased  performance  and  fault  tolerance. 
Performance  improvements  are  possible  because  the  CPU  is  relieved  of  the 
overhead  of  the  bidder,  scheduler  etc.  Because  of  the  proliferation  of 
processors  at  each  node,  it  is  now  also  feasible  to  provide  some  degree  of 
fault  tolerance. 

Preliminary  studies  indicate  that  a  feasible  host  architecture  might 
incorporate  multiple  microprocessors  interacting  through  some  communications 
medium.  We  are  currently  studying  various  architecture  that  seem 
appropriate.  These  studies  include  queueing  models  as  well  as  simulation 
systems  of  these  architectures.  Because  our  algorithm  might  generate  a 
large  number  of  messages  in  the  subnets,  we  are  also  planning  to  study 
various  network  architectures  which  provide  good  connectivity  and  also 
reduce  the  number  of  messages  in  the  subnet. 

Many  real-time  systems  also  have  another  requirement,  i.e.,  robustness. 
We  are  beginning  to  investigate  the  possibilities  of  fault  tolerance  in  our 
system  at  two  level: 

1.  Because  of  the  availability  of  more  than  one  processor  at  the  host,  we 
feel  that  it  is  possible  to  incorporate  tolerance  to  failures  at  a 
processor  by  dynamic  allocation  of  its  tasks  among  the  fault-free  ones. 
The  key  factor  here  is  how  to  decide  if  a  processor  is  faulty.  We  are 
investigating  alternative  schemes  to  do  this. 

2.  At  the  network  level,  we  would  like  to  be  able  to  switch  tasks  between 
hosts  in  the  event  of  a  total  failure  at  a  host. 


2.3  Real-Time  Constraints  *  Resource  Requirements 

We  have  developed  a  heuristic  approach  for  solving  the  problem  of 
scheduling  tasks  with  deadlines  and  general  resource  requirements.  This  is 
an  extension  of  the  basic  algorithm  we  developed,  and  whose  simulation 
results  were  presented  in  Section  2.1.  The  crux  of  our  approach  lies  in  the 
heuristic  function  we  developed.  This  function  weighs  three  factors.  These 
factors  quantify  a  task's  requirements  (deadlines,  CPU  execution«time  re** 
quirement  and  resource  requirements)  in  such  a  way  as  to  help  develop  a 
feasible  schedule  quickly.  If  a  feasible  schedule  is  found  then  the  set  of 
tasks  are  guaranteeable.  We  have  done  extensive  simulation  to  show  that  our 
approach  works.  We  believe  that  the  results  we  have  developed  in  this  area 
are  significant.  The  results  have  been  fully  described  in  a  paper  written 
during  this  quarter  and  attached  as  Appendix  A. 


3.0  Conclusions  and  Recommendations 

In  this  quarter  we  have  concentrated  in  scheduling  tasks  with  hard 
real-»time  constraints  and  made  significant  progress.  We  will  continue  to 
aggressively  pursue  all  research  areas  described  in  this  report.  Further, 
we  will  begin  to  spend  more  time  on  scheduling  tasks  with  soft  real-time 
constraints.  The  immediate  problems  in  this  area  are  a  full  understanding 
and  modeling  of  clusters  of  processes  and  distributed  groups  of  processes. 
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SCHEDULING  TASKS  WITH  RESOURCE  REQUIREMENTS 
IN  HARD  REAL-TIME  SYSTEMS 


ABSTRACT 


This  paper  describes  a  heuristic  approach  for  solving  the  problem  of  scheduling  tasks 
with  deadlines  and  general  resource  requirements  in  a  dynamic  real-time  system.  The  crux 
of  our  approach  Ues  in  die  heuristic  function  used  to  select  die  task  to  be  scheduled  next. 
The  heuristic  function  is  weighted  three  factors.  Each  factor  explicitly  considers  information 
about  real-time  constraints  of  tasks  and  utilization  of  resources.  Simulation  studies  show 
that  the  weights  for  die  various  factors  in  the  heuristic  function  have  to  be  fine-tuned  in 
order  to  obtain  a  degree  of  success  comparable  to  that  obtained  via  exhaustive  search.  In 
addition,  modifying  die  heuristic  to  use  limited  backtracking  improves  die  degree  of  success 
substantially.  This  improvement  is  observed  even  when  the  initial  set  of  weights  are  not 
tailored  for  a  particular  set  of  tasks.  Simulation  studies  also  show  that  in  most  cases  the 
schedule  determined  by  the  heuristic  algorithm  is  optimal  or  dose  to  optimal. 


1*  Introduction 


Loosely  coopted,  mhime  distributed  systems  are  becoming  more  prevalent  in 
applications  such  —  endear  power  plants  and  proceu  control  [SCH064].  The—  systems 
contain  many  tasks  which  have  severe  real-time  constraints.  In  fact,  the—  applications 
require  that  the—  tasks  have  execution  deadlines  that  must  be  met  and  are  thus  said  to 
have  hard  real-time  constraints.  In  practice,  many  solutions  used  today  — «««  complete 
and  prior  knowledge  of  the  task  sets,  induding  their  deadlines,  worst  case  computation 
times,  precedence  relations  and  resource  requirements.  Incorporating  ail  this  knowledge  in  a 
static  way  makes  the  system  inflexible  and  costly  (each  system  is  unique).  Also,  most 
current  research  in  this  area  is  restricted  to  multiproc— ring  systems,  is  compute  bound  and 
do—  not  adapt  to  the  dynamics  of  the  systems.  Our  goal  is  to  develop  a  flaribto 
scheduling  algorithm  for  loosely  coupled  distributed  systems  that  do—  not  require  complete 
and  prior  knowledge,  is  not  compute  bound,  and  quickly  adapts  to  the  dynamics  of  the 
"entire”  system.  Our  basic  algorithm  and  approach  have  been  reported  in  [RAMA84].  This 
paper  reports  on  a  sophisticated  extension  to  our  basic  algorithm.  In  die  remainder  of  this 
section,  we  briefly  describe  Our  basic  approach  and  identify  exactly  how  this  paper 
significantly  extends  the  basic  algorithm. 

Our  basic  approach  [RAMA84]  assumes  that  each  node  of  a  loosely  coupled 
distributed  system  contains  a  local  scheduler,  a  bidder  and  a  dispatch—.  The  local 
scheduler  at  a  node  is  invoked  when  a  new  task  arrives  at  that  node.  It  dead—  if  the  new 
task  can  be  guaranteed  at  this  node.  The  guarantee  means  that  no  matt—  what  happens 
(except  failures)  this  task  will  execute  by  its  dea dllne,  and  that  all  previously  guaranteed 
tasks  will  also  still  me—  their  deadlin—  If  the  new  task  cannot  be  guaranteed  locally,  then 
the  new  task  is  eith—  terminated  (without  executing)  or  is  sent  to  anoch—  node  chosen  on 


the  bub  of  a  bidding  scheme.  The  bidder  on  a  node  is  responsible  tor  1)  sending  out 
requests  fee  bids  for  a  task  that  cannot  be  guaranteed  locally,  2)  evaluating  bids  from  ocher 
nodes,  and  3)  sending  the  task  to  the  best  bidder.  It  also  makes  bids  in  response  to 
requests  from  other  nodes.  The  dispatcher  is  the  system  program  that  actually  schedules  the 
guaranteed  tasks.  It  should  be  pointed  out  that  when  a  node  bids  for  a  task,  it  does  not 
reserve  CPU  time  for  that  task.  Reserving  CPU  time  ties  up  too  many  resources  for  too 
long  a  time.  Consequently,  when  a  bidding  task  finally  arrives  at  a  bidder  node,  the  node 
will  again  try  to  guarantee  it  lit  case  this  guarantee  fails,  die  task  may  be  robidded  again, 
or  declared  as  not  "guaranteeabte**.  In  our  approach,  each  of  die  functions  of  the  local 
scheduler,  bidder,  and  dispatcher  is  carefully  controlled  in  order  to  handle  real-time 
constraints. 

In  our  basic  algorithm  [RAMA84],  a  task  is  characterized  by  a  computation  time  and 
a  deadline.  Tasks  are  assumed  to  be  independent.  We  also  assume  that  resources  are 

always  available  to  the  executing  task.  In  this  paper,  we  relax  this  assumption.  We  now 

allow  a  task  to  request  any  number  of  resources,  including  CPU,  I/O  devices,  files,  etc. 
This  means  that  our  local  scheduling  algorithm  must  be  modified  to  consider  not  only 
computation  time  and  deadlines  of  tasks  but  also  their  resource  requirements.  This  is  a 

significant  extension  to  the  previous  scheduling  algorithm.  This  paper  focuses  on  the  local 

scheduler  portion  of  the  scheme.  In  particular,  we  describe  a  technique  for  deciding 
whether  a  set  of  tasks  on  a  node  can  be  guaranteed  to  execute  on  that  node. 

The  work  described  in  this  paper  is  not  only  an  extension  to  our  own  work,  but  also 
to  work  in  the  field  in  general.  Most  related  work  on  scheduling  tasks  with  hard  real-time 
constraints  is  restricted  to  uniprocessor  and  multiprocessor  systems  [MUNT70,  LIU73, 
DERT74,  JOHN74,  GARE75,  MOK78,  and  TEK78]  and  typically  do  not  take  tasks' 


resource  requirements  into  account.  In  his  work,  Ldnbaugh  [LEIN80  and  LEINS]  dealt 
with  resource  requirements.  He  developed  analysis  algorithms  which,  when  given  the 
resource  requirements  of  each  task,  determine  an  upper  bound  on  the  response  time  of 
each  task.  While  his  approach  is  useful  at  system  design  time  to  statically  determine  the 
upper  bounds  on  response  times,  there  is  no  attempt  at  guaranteeing  that  a  new  task  will 
meet  its  deadline. 

On  the  other  hand,  because  of  die  difficulty  of  the  problem,  heuristic  approaches 
have  been  taken  for  related  scheduling  problems  [EFE82  and  MA84],  that  is,  heuristics  are 
used  in  their  systems.  According  to  Lenat  [LEN82  and  LEN83],  heuristics  are  informal, 
judgmental  rules  of  thumb  which  come  in  two  types:  those  that  actively  guide  the  system 
toward  plausible  paths  to  follow  and  those  that  guide  the  system  away  from  implausible 
ones.  Ma  and  Efe  use  heuristics  which  guide  their  systems  away  from  implausible  paths. 
This  approach  of  only  using  the  second  type  of  heuristic  is  limited  because  in  the  worst 
case,  the  exponential  problem  cannot  be  avoided  QEFE82  and  MA84].  In  our  heuristic 
algorithm,  we  use  both  types  of  heuristics.  We  develop  a  heuristic  function  which 
syntheazes  the  various  factors  of  real-time  scheduling  considerations  to  actively  direct  the 
scheduling  process  to  a  plausible  path.  We  also  constraint  the  search  space  by  looking  only 
at  strongly  feasible  paths,  preventing  us  from  looking  at  implausible  paths.  As  a  remit, 
even  in  the  worst  case,  our  scheduling  algorithm  is  not  exponential.  Moreover,  simulation 
results  show  that  our  heuristic  algorithm  can  guarantee  an  arbitrary  set  of  feasible  tasks 
almost  all  the  time.  It  is  also  shown  that  in  mom  cases  the  schedules  found  by  our 
heuristic  scheduling  algorithm  are  optimal  or  dose  to  optimaL 


In  the  remainder  of  this  paper.  Section  2  provides  an  overview  of  our  heuristic 
approach  for  incorporating  rewaice  requirements  into  dynamic  hard  reaMme  «***■»■; 
while  Section  3  presents  the  algorithm  for  the  local  scheduler,  and  tfsaaees  tb*  heuristic 
function  in  detail.  An  evaluation  of  the  algorithm,  in  Section  4,  shows  that  the  algorithm 
is  effective.  However,  this  initial  evaluation  also  suggests  improvements  that  are  presented 
and  evaluated  in  Section  S.  Analyses  of  the  complexity  and  optimality  of  the  algorithm  are 
made  in  Section  6.  Section  7  concludes  the  paper  with  discusrioos  of  the  achievements  and 
extensions  of  this  study. 


2.  Strategy  and  Function  of  the  Sdiednler 


This  section  first  defines .  end  discusses  the  basic  terms  needed  to  nnA»r«»gwH  our 
scheduling  algorithm.  It  then  outlines  the  strategy  followed  by  die  scheduler,  and  finally 
discusses  an  analogy  between  scheduling  and  searching. 


21  Resources  and  Tasks 

Let  each  nod*  of  a  loosely  coupled  distributed  system  contain  a  set  of  resources,  Rj, 
Rj,  Rj.  A  resource  can  be  serially  shared  by  tasks.  Hie  types  of  resources 
CPU,  physical  devices,  and  files.  A  resource  is  active  if  it  has  procesring  power,  otherwise, 
it  is  pasm*.  For  example,  a  CPU  or  a  physical  device  is  active,  but  a  file  is  passive. 
Tine,  e  passive  resource  must  be  used  with  some  active  resource. 

A  task  is  e  scheduling  entity.  The  following  characteristics  of  a  task,  T,  are  assumed 
known  when  it  arrives: 

1.  The  worst  case  computation  time,  C(T); 


2.  The  deadline,  D(T),  by  which  the  task  must  complete; 

3.  The  resource  requirements  of  the  task.  It  is  asmmed  that  a  task  needs 
napurccs  throughout  its  execution. 


A  task  will  request  at  least  one  active  resource  and  zero  or  more  passive  resources. 


A  tad;  is  said  to  be  guaranteed,  if  the  scheduler  can  decide  on  a  start  time,  so  that 
all  the  resources  needed  by  the  task  are  available  by  that  time,  and  the  task  will  meet  its 
deadline.  A  feasible  schedule  is  a  list  of  tasks  that  have  been  guaranteed.  With  respect  to 

a  set  of  tasks,  a  schedule  is  full,  if  it  contains  all  tasks  in  the  set,  otherwise  it  is  partial. 

% 

A  schedule  (T,,  T2,  T§,  Tf+1)  is  an  immediate  extension  of  the  schedule  cr„  t2,  _  t.)  . 

22  Strategy  of  the  Scheduler 

The  basic  strategy  we  employ  to  determine  whether  or  not  a  new  task  can  be 
guaranteed  on  a  node  is  as  follows: 

L  On  each  node,  there  is  always  a  set  of  guaranteed  tasks,  say  n,  n  m  0,  and  a 
current  full  feasible  schedule  for  these  tasks. 

2.  When  a  new  task  arrives,  it  can  be  guaranteed  if  a  new  full  feasible  schedule 
exists  for  the  n+1  tasks.  That  is,  the  a  tasks  in  the  current  feasible  schedule  remain 
guaranteed  and  die  deadline  of  the  new  cask  also  can  be  met. 

3.  If  die  new  task  is  guaranteed,  then  the  new  feasible  schedule,  containing  die 
new  task  and  the  n  old  tasks,  replaces  the  current  one.  This  feasible  schedule 
determines  all  the  start  times  for  the  tasks  currently  on  the  node,  and  will  not  be 
altered  until  another  new  task  is  guaranteed. 

4.  If  the  new  task  cannot  be  guaranteed,  that  is,  the  local  scheduler  cannot  find  a 
full  feasible  schedule  for  all  u+1  tasks,  bidding  is  invoked  [RAMA84],  The  new  task  is 
sent  to  dm  node  ottering  the  best  bid.  The  original  current  feasible  schedule  for  the 
tasks  previously  guaranteed  on  the  sending  node  remains  unchanged. 


In  tbe  discussion  of  our  heuristic  in  this  paper,  we  asnme  that  die  current  running 
task  is  preemptabte  on  ail  its  resources.  A  minor  modification  is  required  to  deal  with  the 
situation  where  the  currently  running  task  is  not  preemptablc.  We  discuss  this  modification 
in  Section  3X 

hi  the  rest  at  this  paper,  we  will  focus  on  the  algorithm  for  determining  whether  a 
full  feasible  schedule  exists  for  a  given  set  of  tasks. 

23  Scheduling  and  Searching 

The  scheduler  determines  a  full  feasible  schedule  for  a  given  set  of  tasks  in  the 
following  way:  It  begins  with  an  empty  schedule  and  tries  to  extend  it  with  one  task  at  a 
time  until  a  full  feasible  schedule  is  derived.  This  is,  in  fact,  a  search  problem.  The 
structure  of  the  search  space  is  a  search  tree.  The  root  of  the  search  tree  is  the  empty 
schedule.  An  intermediate  vertex  of  the  search  tree  is  a  partial  schedule.  A  descendant  of 
a  vertex  is  an  immediate  extension  of  the  schedule  corresponding  to  the  vertex.  A  leaf,  a 
terminal  vertex,  is  a  full  schedule.  Note  that  not  all  leaves  will  correspond  to  feasible 
schedules.  The  goal  of  our  algorithm  is  to  search  for  a  leaf  that  corresponds  to  a  full 


feasible  schedule. 


3.  The  vSchednHng  Algorithm 


This  section  describes  the  heuristic  scheduling  algorithm.  We  first  present  several  data 
structures  used,  motivate  a  constraint  on  the  search  process,  and  then  present  the  algorithm. 
An  extension  to  the  algorithm  is  discussed  in  Section  5. 


3J  Data  Structures 


The  algorithm  maintain*  a  vector  EAT,  to  indicate  the  Earliest  Available  Times  at 


EAT  -  (EAT,,  EAT2,  _  EAT,) 

where  EAT,  is  the  earliest  time  when  resource  R,  will  become  available.  Initial  values  of 
EAT,  for  all  i  will  be  0  if  the  running  task  is  preemptabto.  Otherwise,  EAT,  will  be  the 
time  when  die  running  task  finishes  using  it.  Each  time  the  partial  schedule  is  extended; 
EAT  will  be  updated  taking  into  account  the  newly  added  task's  resource  requirements  and 
completion  time. 

At  each  level  of  the  search  tree,  the  scheduler  computes  EST(T)  and  New-EAT(T) 
for  each  task  T  that  remains  to  be  scheduled.  EST(T)  indicates  the  Earliest  Start  Time  at 
task  T  if  it  is  scheduled  next.  Since  a  task  T  can  run  only  when  ail  resources  it  needs  are 
available,  we  define  EST(T)  as 

EST(T)  -  MAX(EAT,  where  T  needs  R^. 


MS,- s 


New-EAT(T)  is  a  vector  with  the  same  size  as  EAT  and  contains  the  EAT  values  if 
task  T  b  scheduled  next.  In  other  words,  New-EAT(T)  will  replace  the  current  EAT  if  task 
T  b  scheduled.  The  computation  of  New-EAT(T)  b  illustrated  by  the  following  example.  — 

EXAMPLE  Assume  we  have  7  resources  R,,  Rj,  ....  R,,  and  among  them  R,,  R,,  R,,  and 
R4  are  active  resources.  Let  current  EAT  be 

(1)  EAT  -  (EAT,,  EAT2,  EAT3,  EAT4,  EATj,  EATg,  EAT7) 

-  (  5,  10,  25,  15,  10,  15,  5  ),  and 

let  task  T  with  computation  time  C  -  10,  and  with  resource  requirements  R,,  Rj  and  Rj, 
be  one  of  the  tasks  that  remain  to  be  scheduled. 

First,  the  EST,  the  Earliest  Start  Time  for  T  b 

(2)  EST(T)  -  MAX(EAT,,  EAT2,  EATj) 

-  MAX(  5,  10,  10  )  -  10. 

Then  New-EAT(T)  should  be 

(3)  New-EAT(T)  -  (20,  20,  25,  15,  20,  15,  5) 

because  T  b  assumed  to  start  at  its  EST  and  it  uses  10  units  of  computation  time  while 
holding  R,,  Rj,  and  R,.  R,  will  be  idle  from  time  5  to  10.  Our  scheduling  algorithm 
b  designed  to  minimize  such  idle  times. 

New-EAT(T)  may  be  further  refined  if  we  distinguish  active  resources  from  passive 
ones.  Because  a  passive  resource  must  be  used  with  active  ones,  no  task  can  use  them 
until 

time  *  MIN(New-EAT.  where  R,  b  an  active  resource) 

-  NQN(New-EATj,  New-EAT2,  New-EAT,,  New-EAT^  -  15. 


Thus,  (3)  should  be  further  updated  as 

(4)  New~EAT(T)  -  (20,  20,  25,  15,  20,  15,  15) 

That  is,  all  New-EATjS  for  passive  resources  should  not  be  less  than  (therefore  must  be 
updated  to  be  equal  to)  die  minimum  New-EAT,  for  active  resources. 

AtTM  each  level  of  die  search,  the  scheduler  also  calculates  a  vector  called  DRUR, 
the  Dynamic  Resource  Utilisation  Ratio ,  which  indicates  the  degree  to  which  ta«ir«  that 
remain  to  be  scheduled  will  use  resources: 

DRUR  -  (DRUR,,  DRUR,,  DRUR,) 

where  DRUR,  is  defined  as 

X  (  C(T),  T  remains  to  be  scheduled  and  uses  R^ 

DRUR,  -  - 

MAX(D(T),  T  remains  to  be  scheduled  and  uses  R^  -  EAT, 

where  i  -  1,  ....  r. 

Note  that  all  DRUR,  of  a  DRUR  associated  with  a  partial  feasible  schedule  should 
be  less  than  or  equal  to  1  for  die  remaining  tasks  to  be  scheduled.  EAT,  New-EATs  and 
DRUR  are  updated  each  time  the  partial  schedule  is  extended. 

32  A  Constraint  on  the  Search 

Using  the  data  structures,  EAT  and  DRUR,  described  above,  we  can  state  a 


constraint  on  the  search  for  a  full  feasible  schedule. 


We  define  a  feasible  partial  schedule  to  be  strongly  feasible  if 

L  DRUR  associated  with  the  schedule  has  DRURj  s  1  for  i  -»  1,  r;  and 

2.  all  of  its  iwinwHiat*  extensions  are  feasible. 

A  full  feasible  schedule  is  defined  to  be  strongly  feasible. 

If  a  schedule  is  not  strongly  feasible  because  condition  1  or  2  fails,  then  the  failed 
condition  will  also  fail  fat  all  descendants  of  the  noo-strongiy  feasible  schedule.  Hence, 
none  of  the  descendants  of  a  noo-strongly  feasible  schedule  can  be  strongly  feasible.  On  the 
other  hand,  the  ancestor  of  a  fell  feasible  schedule  must  be  strongly  feasible,  otherwise  the 
fell  schedule  itself  will  not  be  feasible.  Therefore,  only  strongly  feasible  schedules  can  lead 
to  a  full  feasible  schedule.  Considering  this  feet,  a  constraint  on  the  search  for  a  fan 
feasible  schedule  is  : 

For  a  partial  schedule  to  bo  extensible  to  a  full  feasible 
schedule ,  the  partial  schedule  should  be  strongly  feasible. 

From  the  viewpoint  of  the  algorithm,  this  means  that  it  is  not  necessary  to  search 
through  a  vertex  corresponding  to  a  noo-strongly  feasible  schedule,  because  a  noo-strongly 
feasible  schedule  will  not  lead  to  a  full  feasible  schedule. 

By  the  above  constraint,  the  search  is  confined  only  to  those  vertices  wife  strongly 
feasible  schedules.  However,  in  fee  worst  case  an  exhaustive  search  may  stQl  be  required, 
which  is  computationally  intractable.  In  order  to  make  the  algorithm  computationally 
tractable,  even  in  the  worst  case,  we  choose  only  one  of  fee  vertices  at  each  level  to 
expand  the  search  tree.  The  vertex  chosen  is  fee  one  which  appears  to  be  most  capable  of 
hading  to  a  feu  feasible  schedule.  It  is  in  this  choice  feat  our  algorithm  provides  a  way  of 
actively  guiding  the  search  toward  a  plausible  path  —  a  feature  that  distinguishes  our 


approach  from  those  of  others.  In  the  next  subsection,  we  discuss  our  algorithm  that 
incorporates  the  heuristics  necessary  to  make  this  choice. 

33  The  Scheduling  Algorithm 

The  pseudo  code  for  our  heuristic  scheduling  algorithm  is  given  in  Fig  1.  Beginning 
with  the  empty  schedule,  the  algorithm  searches  the  next  level  by  expanding  die  current 
vertex  (a  partial  strongly  feasible  schedule)  to  only  one  of  its  immediate  descendants.  If  the 
wnmariiatw  descendant  is  also  a  strongly  feasible  schedule,  the  search  continues  until  a  full 
feasible  is  met.  At  this  point,  die  searching  process  (Le.,  the  scheduling  process) 

succeeds  and  all  the  tasks  are  known  to  be  guaranteed.  If  at  any  level,  a  non-strongty 
feasible  schedule  is  met,  die  algorithm  announces  that  the  searching  (scheduling)  process 
fails  and  that  not  all  die  tasks  can  be  guaranteed.  It  is  possible  to  extend  the  algorithm 
to  continue  the  search  even  after  a  failure  is  found,  and  this  extension  is  discussed  in 


Section  5. 


PROCEDURE  Schedule^ task-set  :  task-type;  VAR  schedule  :  schedule-type); 

(*Puameter  task-set  is  the  fivea  set  of  tasks  to  be  schedule  *) 

("Function  H  is  the  heuristic  function,  being  discussed  in  3.4*) 

BEGIN 

schedule  empty; 

WHILE  NOT  empty(task-set)  DO 
BEGIN 

calculate  EST  and  New-EAT  for  each  task  in  task-set; 
calculate  DRUR; 

IF  not  strongly-feasiblc{schedulc)  THEN 
retum(not  guaranteed) 
prtp 

BEGIN 

apply  function  H  to  each  task  in  the  task-set; 

let  T  be  the  task  with  the  minimum  value  of  function  H; 

task-set  ?*  task-set  -  {  T  }; 

schedule  r™  schedule  +  {  T  }; 

EAT  New-EATCO; 

END; 

END; 

retum(guaranteed); 

END; 

Fig  1  :  The  Heuristic  Scheduling  Algorithm 


Cleariy,  at  each  level  of  the  search,  effectively  and  correctly  identifying  die 
immediate  descendant  is  important  for  the  success  of  the  algorithm.  This  is  the  core  of 
the  algorithm.  We  construct  a  heuristic  function  named  H  to  help  in  the  selection  process. 
At  each  level,  function  H  is  applied  to  all  the  tasks  remaining  to  be  scheduled.  The  task 
with  the  minimum  value  returned  by  function  H  is  selected  to  extend  the  schedule.  The 
next  subsection  discusses  function  H  in  detail. 


34  The  Heuristic  Function 


Function  H  is  defined  as  follows: 

H<T)  -  W,  •  Xj(T)  +  W2  •  XjfT)  +  W3  •  Xj(T) 
where  T  is  a  task,  Wr  W2  and  W3  are  weights  and 

1.  Xj  takes  into  account  die  resource  requirements  of  T  as  well  as  the  resource 
utilisation*-  We  will  further  develop  Xj  later. 

2.  Xj  equals  the  laxity  of  task  T,  and  hence  b  given  by 

Xj(T)  -  D(T)  -  (EST(T).  +  C(T)) 

where  EST(T)  is  die  Estimated  Start  Time  for  task  T  according  to  the  availabilities  of 
resources  it  will  request;  arul  C(T)  is  the  computation  time  of  T. 

3.  Xj  -  CCT). 


Note  that,  if  and  W2  are  zero  ami  W3  -  1,  then  the  task  with  the  least 
computation  time  C  will  be  selected  first;  if  W2  -  1  but  W3  and  W3  are  zero,  the  task 
with  die  least  laxity  will  be  selected  first  Simulation  results  given  in  Section  4  show  that 
neither  of  the  scheduling  polices  are  appropriate.  However  if  die  three  weights  are  properly 
chosen,  we  find  that  function  H  provides  effective  selection  information. 

Now,  we  further  elaborate  the  first  part  of  function  H.  X,  is  defined  as: 

X,  -  DRUR  •  DRJF 

where  •  stands  for  dot  producr,  DRUR  is  die  Dynamic  Resource  Utilization  Ratio 
asKxnatcd  with  the  current  partial  schedule,  as  defined  in  section  34;  DRIF  is  the  Dynamic 


Resource  Idle  Factor. 


The  Dynamic  Resource  Idle  Factor,  DRIF,  is  a  function  of  the  task  being  considered 
for  expanding  the  current  feasible  schedule.  It  indicates  the  amount  of  time  each  resource 
would  remain  idle  if  the  task  is  selected  next. 


Before  formally  defining  DRIF,  we  discuss  three  different  types  of  idleness.  Consider 
the  example  in  31  again:  In  that  example,  EAT  -  (5,  10,  25,  15,  10,  15,  5);  a  task  T 
remaining  to  be  scheduled  has  C(T)  -  10  and  needs  R,,  R,,  and  Ry  Therefore,  EST(T) 
*  10  and  New-EAT(T)  -  (20,  20,  25,  15,  20,  15,  15).  We  use  a  graph  shown  in  Fig  2  to 
indicate  EAT,  New-EAT(T)  as  well  as  different  idle  times: 
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Task  T  uses  Rj,  Rj,  and  R,  in  the  ana  marked  "U*.  The  other  three  anas  marked 
TP,  "Q*  and  "N"  indicate  dine  different  types  of  idle  time. 

1.  The  area  marked  "I"  is  the  idle  time  of  Rj  and  Ry.  No  task  can  use  this  tfane 
in  the  future  if  T  is  scheduled  next.  Therefore  this  indicates  tfane  that  is  i mired  if 
T  is  scheduled  next. 

2.  The  area  ”N"  is  the  time  task  T  may  run  in  parallel  with  some  other 

task.  For  example,  since  R,  becomes  available  only  at  time  25  then  some  task  may  be 
««ng  ^  until  that  time.  Hence  by  schoriniint  T  next,  them  is  possible  paraildism 
between  T  and  the  task  using  Ry  That  is,  the  area  indicated  by  "N"  is,  in  some 
sense,  rugativ*  idle  time. 

3.  The  idle  time  indicated  by  "Q"  could  be  used  or  wasted,  depending  on  the 
tasks  selected  later.  For  example,  if  die  next  task  needs  R4  and  R*,  then  die  time 
areas  marked  by  "Q"  under  R4  and  Rg  will  be  used.  However  if  die  next  task  needs 
Rj,  R4  and  R*  then  die  areas  marked  by  "Q"  will  be  wasted  idle  time. 

By  die  above  example,  it  is  dear  that  the  three  different  idle  times  should  be  taken  into 
account  differently  because  they  have  a  different  impact  on  the  system.  We  define 

DRIF(T)  -  DRIF-I(T)  +  DRIF-N(T)  +  DRIF-Q(T) 
where  DRIF-I,  DRIF-N,  and  DRIF-Q  represent  the  three  types  of  idle  times  on  resources. 

DRIFT  corresponds  to  the  T*  idle  time  on  each  resource,  and  is  defined  as 

DRIF-IjCT) 

DRIFTjfT) 

DRIF-ICT)  * 

•  • 

•  • 

,  DRIF-IjCT) . 


-  17  - 


where  far  i  ■  1,  r 


f  EST(T)  -  EAT, 


if  T  needs  R,, 


DRIF-^CT)  -  | 

{  New-EATj(T)  -  EAT,  ebe. 

Recall  dial  EST(T)  is  the  time  Task  T  can  begin  to  use  R,,  and  that  EAT,  teQs  us  when 
R,  is  available.  Then  the  difference  between  EST(T)  and  EAT,  is  the  wasted  idle  time  on 
R,  if  T  needs  R,.  However,  even  if  T  does  not  need  a  resource  R,,  R,  may  be  idle  if  R, 
b  passive  and  its  EAT,  b  less  than  that  of  any  active  resource,  such  as  Ry  in  the  example 
of  Fig  2.  The  second  case  of  the  formula  computes  this  wasted  idle  time. 

DRIF-N  indicates  die  negative  idle  times  on  resources,  and  b  defined  as 


DREF-N(T)  - 


{  DRIF-NjCT) ) 
j  DRIF-NjCT)  j 


l  DRIF-Nr(T)  ) 


where  for  i  ■  1,  ...,  r 


DRIF-N-CO  -  j 


if  T  needs  R,, 
or  EAT,  <  EST(T), 


l  -  M3N(EAT,  -  EST(T),  C<T))  ebe; 

The  first  case  indicates  that  there  b  no  negative  idle  time  for  a  resource  if  T  needs  it,  or 
if  it  b  available  before  T  runs.  The  second  case  computes  the  negative  idle  times  for  a 
resource  which  b  not  available  at  the  time  T  executes.  Its  negative  idle  times  b  defined  to 
be  the  portion  of  time,  in  which  the  resource  b  not  available  while  T  b  running.  For 

example,  in  Fig  2,  Rj  and  R4  have  the  following  negative  idle  times  : 

DRXF-Nj  -  -  MIN(EAT3  -  EST(T),  C(D)  -  -  MIN(15,  10)  -  -  10,  and 

DRIF-N4  -  -  MIN(EAT4  -  EST(T),  C(T))  -  -  MIN(5,  10)  -  -  5. 


/V 


DRIF-Q  is  a~**j**a  to  reflect  the  "O’*  idle  times  : 

f  DRIF-Q,C T) 

DRIF-Qj(T) 

DRIF-QCT)  - 

•  • 

,  DRIF-C^fT) . 
where  for  i  -  1,  r 

0  if  T  need 

DRiF-qcr)  - 


if  T  needs  Rj,  or  EAT{  >  EST(T)  +  C(T) 


(  WgC  EST(T)  +  C(T)  -  New-EATjCT)  )  else. 

There  is  no  "Q”  idle  time  for  a  resource  if  it  is  needed  by  T,  or  if  it  is  unavailable 
during  the  execution  of  T.  This  is  the  first  case  in  the  above  formula.  In  the  example  of 
Fig  2,  R,,  Rj,  Rj  and  Rj  all  have  "Q”  idle  times  equal  to  zero.  The  second  case  deals 
with  resources  that  are  available  during  the  execution  of  task  T.  The  time  duration 
between  the  time  the  resource  is  available,  New-EATj,  and  the  time  T  completes,  (E5T(T) 
+  CCD),  is  the  ”Q"  idle  time.  Because  it  is  not  certain  whether  in  this  duration  the 
resource  will  be  used  or  wasted,  we  multiply  it  by  a  factor  WQ  which  we  choose  between  0 
and  1.  For  all  the  tasks  presented  here  W0  *  0.5. 

Then  DRIF  for  task  T  in  Fig  2  is  given  by 
DRIF(T)  «  DRIF-I(T)  +  DRIF-N(T)  +  DRIF-QCD 
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Recall  that  Xj  -  DRUR  •  DRIF,  and  DRUR  reflects  the  degree  of  resource 
utilization  by  the  tasks  remaining  to  be  scheduled.  The  dot  product  means  that  we  weight 
each  DRIF!  by  DRURj,  and  sum  them.  Therefore,  X,  actually  is  a  sum  of  weighted 
resource  idle  times. 

To  summarize,  the  heuristic  function  has  been  designed  to  incorporate  not  only  the 
necessary  timing  considerations  but  also  resource  utilizations.  The  simulation  results  shown 
in  the  next  section  indicate  that  it  does  work  quite  well  if  die  appropriate  weights  W3,  W2 
and  W3  are  used. 


4»  Siiaalatioo  Results 


The  pnrpoee  of  the  Emulation  is  to  test  the  performance  of  the  algorithm.  Recall 
that  the  baric  function  of  the  algorithm,  as  described  in  Section  2,  is  to  determine  a  full 
feasible  schedule  for  a  given  set  of  tasks.  In  each  simulation,  we  input  a  number  of  sets  of 
tasks  to  the  local  scheduler  program.  For  each  of  the  input  task  sets  it  is  known  exactly 
how  many  feasible  schedules  exist  and  that  each  set  has  at  least  one  feasible  schedule 
because  we  perform  a  separate  exhaustive  search  procedure  on  each  set  of  tasks.  We  then 
observe  the  percentage  of  task  sets  guaranteed  by  our  heuristic  algorithm.  This 

percentage  is  called  die  success  ratio  at  die  algorithm. 

4J  Task  Generator 

The  Task  Generator  is  a  program  that  generates  tasks  for  our  simulation  study.  It 
uses  three  generating  parameters: 

1.  PI:  minimum  computation  time, 

2.  P2:  maximum  computation  time,  and 

3.  P3:  maximum  laxity. 

The  computation  time  of  a  task  is  randomly  chosen  between  PI  and  P2.  The 
of  a  task  is  randomly  chosen  between  its  computation  time  and  the  computation  time  plus 
P3.  It  is  dear  that  different  application  domains  will  require  different  generating  parameters. 


We  mume  there  are  5  resources,  two  active  resources,  and  three  paanve  resources. 


The  resource  requirements  of  a  task  are  also  chosen  randomly  with  the  condition  that  a 
task  uses  at  least  one  active  resource. 

In  the  current  simulation,  we  collect  6  independent  tasks  to  form  a  set  An 
exhaustive  search  is  made  for  each  set  to  see  how  many  full  feasible  schedules  exist  For 
a  set  of  6  tasks,  there  are  720  permutations,  each  of  which  may  or  may  not  represent  a 
full  feasible  schedule  for  that  task  set  We  purposely  set  up  the  generating  parameters 
used  by  the  Task  Generator  so  that  the  number  of  feasible  schedules  among  720 
permutations  usually  is  very  small,  making  it  fairly  difficult  to  find  a  feasible  schedule. 
Table  0  gives  the  distribution  of  number  of  feasible  schedules  for  a  typical  group  of  200 
sets  of  tasks.  It  shows  that  among  200  task  sets,  input  to  the  scheduler  simulation  program, 
more  than  55%  of  die  task  sets  (14  +  103  -  117  out  (rf  200)  have  at  most  25  full  feasible 
schedules.  And  less  than  5%  of  the  task  sets  (6  +  3  -  9  out  of  200),  have  more  than  100 
full  feasible  schedules. 


Number  of 

Feasible  Schedules 

D 

BQ 

11  -  25  | 

m 

51  -  100  | 

Number  of  Task  Sets 

I 

*  1 

IS  | 

6  |  3 

Percentage  of  Sets  % 

I 

7.0  | 

51.5  | 

2S.0  | 

9.0  | 

3D  |  13 

Ratio  %  12j0  14  S  123 


Table  1  :  Simulation  of  an  H  Function  with  one  Factor 


Table  1  shows  that,  for  a  given  group  (group  _  number  1),  the  scheduling  polices 
corresponding  to  the  "minimum  computation  time  first",  "least  laxity  first"  and  "least 
weighted  resource  idle  time  first"  are  not  effective.  That  is,  when  (W,,  W2,  Wj)  -(0  0  1), 


(0,  1,  0),  or  (1,  0,  0),  the 


ratio  is  lower  than  20%.  However,  for  the  same  group 


as  in  Table  1,  if  we  use  ail  three  weights  and  property  tune  them,  die  success  ratios  can 
be  as  high  as  80%.  This  remit  is  shown  in  Table  2. 


Group  Number  1  (no  change  ) 


Weights  of 
function  H 

wi 

020 

020 

032 

W2 

026 

020 

021 

020 

020 

026 

Guaranteed 

Sets 

148 

152 

162 

Ratio  % 

742 

76.0 

812 

Ratio  85.0%  822%  783%  87j0%  833%  782%  88.0%  823% 

PI  - 10  P2-30  P3-70 

W,  -  030  W2  -  036  W3  -  035 

Table  3  :  8  groups  with  fixed  generating  parameters  and  fixed  weights 

Table  3  indicates  that  with  the  fixed  generating  parameters,  (PI,  P2,  P3)  -  (10,  30 
70),  and  the  fixed  weights  of  function  H,  (W},  W2,  V,^)  -  (030,  036,  025),  the  success 
ratio  varies  among  8  specific  groups  tested  from  a  low  of  78%  to  a  high  88%.  The  range 
of  percentages  is  due  to  the  randomness  of  the  task  generation,  but  the  small  standard 
deviation  of  about  3%,  indicates  the  stability  of  the  scheduling  algorithm.  We  believe  that 
78%  -  88%  is  quite  a  good  success  ratio.  As  we  will  see  in  Section  5,  with  some 


Group  Number  10  11  12  13  14  15 


Generating 

Parameters 


PI 

30 

20 

10 

20 

20 

10 

P2 

50 

60 

160 

40 

100 

30 

P3 

100 

120 

300 

70 

100 

50 

Weights  of 
function  H 

Wi 

025 

028 

020 

022 

024 

026 

w2 

025 

028 

029 

025 

0.18 

020 

w3 

020 

023 

020 

026 

0.14 

024 

Guaranteed 

Sets 

172 

160 

176 

162 

164 

162 

SWTCTf 

Ratio  % 

8623 

80j0 

88 D 

81.0 

820 

81J0 

Table  4  :  Good  Weights  for  6  Groups 


Table  4  lists  the  best  success  ratios  for  an  additional  6  groups,  each  of  which  is 
generated  by  different  parameters.  The  best  success  ratio  for  each  group  is  achieved  by 
tuning  the  weights  of  function  H.  We  see  that  in  order  to  achieve  die  best  success  ratio, 
the  weights  vary  with  groups,  Le.,  W3  varies  between  024  and  025,  W2  varies  between  0.18 
and  025,  and  W3  varies  between  020  and  0.16.  It  is  dear  that  a  set  of  universally  best 
weights  do  not  exist.  However,  we  see  that  the  range  of  the  weights  is  not  very  large, 
suggesting  that  there  may  be  a  set  of  feasible  weights  which  can  cover  adequately  many 
groups  with  different  generating  parameters.  To  substantiate  this  point,  we  average  the 
weights  Wj,  W2,  and  W3  in  Table  4,  and  raise  them  for  the  same  6  groups  shown  in 
Table  4.  Table  5  presents  the  results: 


Group  Number  10 

11 

12 

13 

14 

15 

Generating 

Parameters 

PI 

30 

20 

10 

20 

20 

10 

P2 

50 

60 

160 

40 

100 

30 

P3 

100 

120 

300 

70 

100 

50 

Weights  of 
function  H 

wi 

029 

w2 

021 

(  no  change  ) 

022 

Guaranteed 

Sets 

170 

160 

170 

159 

160 

161 

Success 
Ratio  % 

85  j0 

80.0 

85.0 

79.5 

SOD 

803 

Table  5  :  Using  the  averaged  weights 

With  a  fixed  set  of  average  weights,  we  obtain  an  average  success  ratio  of  more  than 
80%  with  a  standard  deviation  of  only  25%.  The  results  imply  that  though  a  set  of  the 
universally  best  weights  do  not  exist,  one  set  of  feasible  weights  may  cover  many  different 
groups  with  different  generating  parameters.  Therefore  it  seems  that  the  weights  are  not 
too  sensitive  to  die  generating  parameters. 

Although  the  simulation  results  presented  in  this  section  are  only  for  a  limited 
number  of  groups  with  a  limited  number  of  different  generating  parameters,  we  have  tested 
many  other  groups  with  many  different  generating  parameters.  In  all  cases,  the  results  are 
quite  similar.  Due  to  the  lack  of  space,  we  are  unable  to  present  these  additional 
Emulation  results  here.  We  would,  however,  like  to  point  out  that  these  simulation  results 


were  in  consonance  with  die  observations  made  above. 


5.  Extension  on  the  Basic  Algorithm 

la  this  section  we  describe  an  extension  to  the  basic  heuristic  scheduling  algorithm 
discussed  and  evaluated  in  die  previous  sections. 

5J  Extended  Algorithm 

The  assumptions  underlying  the  use  of  the  heuristic  function  in  die  basic  algorithm 
are 

1.  At  each  level  of  the  search,  there  is. a  certain  order  among  the  tasks  to  be 
selected; 

2.  The  order  can  be  idemtfied  by  a  linear  function  such  as  function  H  used  in  our 
primary  algorithm. 

Though  the  first  assumption  is  definitely  true,  die  second  may  not  always  hold,  so 
our  original  algorithm  cannot  always  guarantee  a  set  of  tasks  for  which  there  is  at  least 
one  full  feasible  schedule.  To  improve  the  success  ratio,  the  following  means  were 
considered: 

1.  add  some  non-linear  components  to  function  H; 

2.  change  the  weights  of  function  H  dynamically; 

3.  whenever  a  partial  non-strongiy  feasible  schedule  is  met  while  scheduling,  try  to 
backtrack. 


Though  the  first  two  alternatives  are  more  mathematical  than  the  third,  we  did  not  adopt 
diem  because  the  first  increases  the  computation  cost  on  every  computation  of  function  H, 


and  the  second  could  make  the  algorithm  too  complex.  The  third  method  was  adopted 
became  we  made  an  interesting  observation  from  the  log  files  of  the  primary  algorithm 
runs:  If,  at  the  point  where  a  non-strongly  feasible  schedule  is  met,  die  task  with  die 
second  minimum  value  of  the  function  H  was  selected  instead  of  the  minimum  one,  more 
Him  half  of  the  task  sets  that  were  not  scheduled  by  the  primary  algorithm  become 
schedulabie.  Moreover,  a  majority  of  the  remaining  task  sets  falling  to  be  scheduled 
become  schedulabie  if  we  backtrack  to  an  ancestor  and  select  die  task  with  the  second 
minimum  value  of  function  H  at  that  level,  instead  of  the  minimum  one.  That  is, 
function  H  not  only  tells  us  which  is  the  best  task  to  be  selected,  but  also  gives 
information  about  which  one  is  the  next  best  if  the  best  does  not  work. 

With  this  observation,  the  primary  algorithm,  given  in  Fig  1,  is  extended  in  the 
following  way:  Each  scheduled  task  has  a  pointer  to  the  task  with  the  second  minimum 
value  of  function  H,  and  it  also  records  the  old  EAT  values  before  it  is  scheduled.  This  is 
done  so  that  the  "second  pointer”  and  old  EAT  values  may  be  used  by  possible  future 
backtracks  without  re-calculations  at  that  level.  Each  time  a  non-strongly  feasible  schedule 
is  found,  a  subroutine,  called  the  Lunited-Backtracker,  is  invoked  to 

1.  withdraw  die  task  just  selected  and  added  in  the  schedule,*  and  instead  attempt 
to  schedule  the  task  with  the  second  minimum  value  of  function  H; 

2.  if  the  first  step  does  not  succeed,  that  is,  die  schedule  is  still  non-strongly 
feasible,  recursively  backtrack  to  the  immediate  ancestor  and  attemr*  schedule  the 
task  with  the  second  value  of  function  H  at  the  ancestor  level.  Whenever  a  strongly 

1.  Note  that  the  schedule  is  feasible,  but  not  strongly  feasible,  therefore  die  task 
withdrawn  can  be  guaranteed,  but  some  others  will  not. 


feasible  schedule  is  found,  the  Limited-Backtracker  returns  "success"  to  the  caller,  the 
scheduler  program*  Otherwise,  it  continues  the  recursive  backtrack  until  either  it  has 
backtracked  to  the  root  of  the  search  tree  —  the  empty  schedule,  indicating  that  all 
die  ancestors  have  been  tried;  or  until  a  counter,  which  counts  die  number  of 
backtracks  in  scheduling  this  task  set,  reaches  a  pre-set  upper  bound.  In  these  cases, 
the  Limited-Backtracker  returns  "failed”. 

The  pseudo  code  of  the  algorithm  for  the  Limited-Backtracker  is  shown  in  Fig  3. 
We  call  the  first  step  in  the  Limited-Backtracker  a  pseudo  backtrack  because  it  happens  at 
the  current  search  level  and  function  H  is  not  recalculated.  The  second  step  is  called  retd 
backtrack.  Real  backtracks  do  increase  the  computation  cost  because  they  requires  the 
recalculations  of  function  H  at  (all)  die  levei(s)  (in  search  three)  immediately  below  the 
vertex  in  which  the  real  backtrack  succeeds. 

Note  that,  if  in  the  Limited-Backtracker  we  did  not  limit  the  number  of  real 
backtracks,  then  in  the  worst  case,  the  search  process  might  eventually  expand  two  vertices 
from  each  ancestor,  resulting  in  a  computation  time  proportional  to  2°,  where  n  is  the 


number  of  tasks. 


29 


Procedure  Limited-Backtracker(VAR  task-set  :  task-set-type;  VAR  schedule  :  schedule-type); 

(•  Limited-Backtracker  is  called  by  die  scheduler  when  the  (partial)  schedule  is  found 
noo-strongly  feasible.  Task-set  contains  die  tasks  remaining  to  be  scheduled; 
schedule  is  die  non-stroogly  feasible  schedule.  *) 

BEGIN 


(•first,  we  do  die  pseudo  backtrack*) 
let  T1  be  the  last  task  in  the  schedule; 
remove  T1  from  the  schedule; 

let  T2  be  the  task  with  the  second  H  value  pointed  to  by  the 
task-set  task-set  +  {11}  •  {T2}; 
put  T2  at  the  end  of  die  schedule; 

IF  strongiy-feasible(schedule)  THEN 
return(success) 

ELSE 


("the  real  backtrack  starts") 

WHILE  NOT  empty(schedule)  and  counter  <  max-counter  DO 
BEGIN 

("withdraw  from  the  end  of  the  schedule  all  die  tasks 
with  a  second  minimum  value  of  function  H. 

This  kind  of  tasks  have  their  "second  pointer”  nil.") 
REPEAT 

let  T1  be  the  last  task  in  the  schedule; 
remove  T1  from  the  schedule; 
task-set  task-set  +  {  T1  }; 

UNTIL  TTs  "Second  pointer”  o  nil; 


"Second  pointer”  of  Tl; 


EAT  old-EAT  stored  with  Tl; 

let  T2  be  die  task  pointed  by  Tl's 

task-set  :*■  task-set  •  {T2}; 

put  T2  at  the  end  of  the  schedule; 

if  strongly-feasible(schedule)  then 
return(success); 

counter  counter  +  1; 
END(*WHILE*); 


’second  pointer”; 


retum(fai]ed); 

END; 


Fig  3  :  The  Algorithm  of  the  Limited-Backtracker 


*•  y*.\\  \  -.i  r.-  .■  .■ . 
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Simulation  Studies  on  the  Extended  Algorithm 

The  route  of  emulation*  for  die  extended  scheduling  algorithm  are  shown  in  Table  6 


Group  Number 


(no  change) 


Generating 

Parameters 

PI 

30  (no  change) 

Weights  of 

function  H 

w. 

020 

0  26 

024 

W2 

020 

020 

020 

w. 

020 

0.16 

024 

Max  Real 


725 

77j0 

810 

900 

942 

952 

SRq  :  die  bade  success  ratio  without  any  backtrack 
SR,  :  the  success  ratio  without  any  real  backtrack 
SR,  :  the  success  ratio  with  pseudo  and  real  backtracks 


Table  6  :  Simulation  Results  of  the  Scheduling  Algorithm  with  Limited  Backtracking 

From  Table  6,  first,  we  can  see  that  though  the  success  ratios  without  backtracks 
(SRg)  varies  with  Afferent  sets  of  weights  from  72.5%  to  81%,  using  pseudo  backtracks  a 
SBceem  ratio  (SR^  of  between  90%  and  95%  results.  The  final  success  ratio  with  pseudo 
and  real  backtracks  (SRj)  is  no  less  than  95%  and  can  be  as  high  as  99.5%.  Thus,  though 
the  scheduling  costs  increase  with  the  use  of  backtracking,  the  success  ratio  increases 


Secondly,  we  may  notice  mat  this  emulation  u  one  group  with  three  fairly  different 
sets  of  weights.  In  all  three  cases,  the  final  success  ratios  are  surprisingly  high.  This 
indicates  that  with  backtracking,  tuning  of  weights  is  less  important  than  in  the  primary 

algorithm.  This  is  because  backtracking  is  more  resilient  in  the  sense  of  allowing  wrong 

% 

choices  to  be  rectified. 

Table  7  lists  the  results  of  simulation  with  a  set  of  fixed  weights  for  5  different 
groups  over  a  range  of  generating  parameters.  We  observe  that  with  limited  backtracking,  a 
set  of  common  weights  is  not  only  feasible,  but  is  also  sufficient.  The  success  ratio  is 
higher  than  96%  if  backtracks  are  allowed. 


Group  Number 

Generating 

Parameters 


23  24  25 


PI 

20 

30 

20 

20 

50 

P2 

50 

50 

60 

120 

200 

P3 

70 

100 

80 

150 

300 

SRq  % 

8L5 

75j0 

82.5 

715 

72.0 

SR,  % 

965 

90.0 

91.5 

94.0 

92  5 

SRj  % 

99  5 

97.5 

96 a 

99.5 

98.0 

Max  Real 

Backtrack 

2 

7 

11 

5 

5 

SRq,  SRj,  and  SR^  have  the  same  meanings  as  in  Table  6 
W,  -  026,  W2  -  020,  W3  -  024 

Table  7  :  One  Set  of  Weights  for  Different  Groups 


Tables  6  and  7  also  list  the  maximum  numbers  of  real  backtracks  used  for  each 
group  of  200  task  sets.  Note  that  usually  no  more  than  10%  of  task  sets,  (SRj  -  SRq), 
use  real  backtracks.  The  numbers  of  real  backtracks  used  by  those  task  sets  often  are  very 
small.  Tables  6  and  7  indicate  that  even  the  maximum  number  of  real  backtracks  for  a 


6.  Coniplrrity  and  OptimaHty 


la  d Us  section  we  dbcuss  the  dm*  complexity  of  die  algorithm,  propose  several 
metrics  of  optimality,  and  illustrate  bow  wed  our  algorithm  performs  in  terms  of  these 
optimality  measurements. 


61  Time  Complexity 

The  major  computation  happens  at  the  calculations  of  function  H.  Each  calculation  of 
function  H  takes  time  proportional  to  r.  Function  H  is  invoked  (S  1  0*1,  a))  dm**, 

resulting  in  the  total  time  complexity  of  ra2.  Pseudo  backtracks  do  not  increase  the 
computational  complexity.  However,  die  computation  cost  increased  by  real  backtracks 
cannot  effect  die  total  complexity,  so  long  as  dm  upper  bound  of  real  backtracks  is  pre-set 
to  less  than  a2.  Our  simulation  results  in  Section  S  showed  that  die  number  of  real 
backtracks  was  usually  quite  tow.  The  time  complexity  nr2  of  our  heuristic  scheduling 
algorithm  is  fairly  tow  compared  to  that  of  an  exhaustive  search  algorithm  which  takes 
time  proportional  to  mL 

62  Optimality 

Before  discnsting  optimality,  we  need  to  chose  some  metrics  suited  for  hard  real-time 
environments.  For  a  full  feasible  schedule  we  propose  the  following  metrics  : 

1.  Task  Set  Completion  Thu  :  This  is  die  time  when,  according  to  die  full  feasible 


schedule,  all  tasks  can  be  completed.  Thus  it  reflects  the  system  response  time. 


2.  Average  utUixatUm  ratio  cf  resources  :  Ibis  is  the  avenge  of  resource  utilization 
ratios  of  the  tasks  in  the  full  feasible  schedule.  Ibis  is  one  of  the  traditional  metrics 
of  optimality  for  scheduling  algorithms. 

3.  Average  laxity  :  This  is  defined  as  the  average  of  the  differences  between 
deadlines  and  scheduled  completion  times  of  all  tasks  in  the  full  feasible  schedule.  This 
is  a  metric  indicating  the  average  laxity  of  completed  tasks. 

4.  Minimum  laxity  :  The  minimum  of  differences  between  deadlines  and  scheduled 
completion  times  of  all  tasks  in  die  full  feasible  schedule.  We  can  postpone  executing 
tasks  by  this  amount  so  that  a  newly  arriving  task  may  be  executed  before  them. 

For  each  set  of  tasks  input  to  the  scheduler  simulation  program,  using  exhaustive 
search,  we  calculate  the  following: 

1.  die  values  of  die  four  metrics  for  each  permutation  that  represents  a  feasible 
schedule;  and 

2.  die  optimal,  average,  and  wont  values  of  each  metric  among  all  permutations 
representing  feasible  schedules. 

With  respect  to  each  metric,  the  full  feasible  schedule  determined  by  our  extended 
heuristic  algorithm  is  ranked  as  follows: 

1.  optimal ,  if  its  performance  under  that  metric  is  equal  to  die  optimal  one  found 
above; 

2.  good,  if  its  performance  is  worse  than  the  optimal  but  better  than  or  equal  to 


the  average  value; 


3.  poor,  if  its  performance  is  worse  than  the  average,  but  better  than  the  wont; 

4.  went,  it  its  performance  is  equal  to  the  worst 

In  some  cases,  the  optimal  and  wont  values  of  a  metric  for  a  set  of  tasks  are  equal. 
Then,  if  the  scheduler  guarantees  the  set  of  tasks,  the  full  feasible  schedule  will  have  the 
same  value  of  the  metric  as  the  optimal  as  well  as  the  worst  one.  Such  a  full  feasible 
schedule  is  termed  optimal. 

Simulation  results  for  one  group  of  200  sets  of  tasks  are  shown  in  Table  8.  In  that 
simulation,  the  final  success  ratio  is  985%,  therefore  total  197  sets  of  are  guaranteed 
and  their  full  feasible  schedules  are  ranked  according  to  the  optimality  metrics  above. 


measurements 

optimal' 

optimal 

good 

poor 

worst 

Set  Completion  Time 

137 

25 

6 

7 

22 

Average 

Utilization 

97 

15 

80 

4 

1 

Average 

Laxity 

42 

37 

45 

45 

28 

Minimum 

Laxity 

94 

85 

3 

6 

9 

PI  - 

10 

W,  -  056 

Input  sets  at  tasks 

-  200 

P2  - 

30 

W2  -  025 

Success  Ratio  % 

-  985 

P3  - 

70 

w3  -  001 

Compared  sets  of  tasks 

-  197 

Table  8  :  Comparisons  of  Optimalities 


From  Table  8,  we  see  that  the  full  feasible  schedules  found  by  die  scheduler  are 
optimal  or  dose  to  optimal  most  of  the  time.  For  example,  using  average  resource 
utilization  as  a  metric,  we  found  that  in  97  +  15  -  112  cases  out  of  197,  our  algorithm 
found  the  optimal  solutions,  and  another  80  out  of  197  are  dose  to  optimal  (that  is,  good). 
Simulations  and  comparisons  made  for  many  other  groups  had  similar  results.  We  believe 
that  these  results  indicate  that  by  developing  a  good  heuristic  function  and  tuning  the 
weights  properly  one  can  expect  extremely  good  results  from  this  approach. 


7.  Concfnstons 

The  problem  of  detennining  an  optimal  schedule  is  known  to  be  NP-hard  [GRAH79] 
and  ia  hence  impractical  for  real-time  task  scheduling.  The  problem  is  further  complicated 
when,  in  addition  to  computation  times  and  deadlines  of  tasks,  their  resource  requirements 
are  also  accounted  for. 

In  this  paper,  we  described  a  heuristic  approach  to  solving  tins  problem.  The  crux  of 
our  approach  lies  in  the  heuristic  function  used  to  select  the  task  to  be  scheduled  next.  It 
uses  information  about  tasks'  real-time  constraints  and  resource  utilizations.  Simulation 
studies  showed  that  the  weights  for  the  various  factors  that  affect  the  scheduling  decisions 
have  to  be  fine-tuned  in  order  to  obtain  a  degree  of  success  comparable  to  that  obtained 
via  exhaustive  search.  However,  use  of  limited  backtracking,  whereby  in  case  of  a  failure, 
previous  scheduling  decisions  are  rescinded  and  new  decisions  are  made,  was  observed  to 
improve  the  degree  of  success  substantially.  This  improvement  was  observed  even  when  die 
initial  set  of  weights  were  not  tailored  for  a  particular  set  of  tasks.  Simulation  studies  also 
showed  that  in  most  cases  the  full  feasible  schedule  determined  by  the  heuristic  algorithm 
was  optimal  or  dose  to  optimal. 

Given  that  the  heuristic  approach  to  task  scheduling  with  resource  constraints  has 
been  highly  successful,  we  plan  to  incorporate  it  in  our  distributed  scheduling  algorithm. 
This  will  involve  extensions  to  the  basic  bidding  technique  [RAMA84].  In  particular, 
modifications  have  to  be  made  regarding  the  information  that  is  sent  on  bids  so  that  a 
requesting  node  can  evaluate  bids  and  determine  the  best  bidder. 
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